Within operating systems, files are typically stored in logical groups referred to as "directories" or "folders". While some computer programs require particular files to be stored in particular places to operate correctly, the decision about how to organize files within operating system directories is largely left to the user. For example, one user may create a single directory to store all computer games, while another user stores each computer game in a separate directory.
Unfortunately, database systems do not reflect the same flexibility with respect to grouping data items as operating systems do with respect to grouping files. Specifically, database systems typically support two types of logical groupings: the logical grouping of data items into data containers, and the logical grouping of data containers and other types of schema objects into schemas. In both cases, membership within the logical groupings is restricted by certain constraints. These constraints significantly limit the purposes for which the logical groupings can be used.
Specifically, the data container to which a data item belongs in a database dictates the format and content of the data item. Thus, data items that have similar characteristics are stored within the same logical containers. For example, in traditional relational database systems, the user data is stored in tables. Each row within a table has values for the same fields, where the fields are dictated by the columns of the table. Recently, database systems are moving toward the object-oriented paradigm, where data is stored as objects which belong to object classes. Each object class defines certain attributes, and all objects that belong to a given object class have values for the attributes defined by the object class. Some databases combine the relational and object-oriented database models by allowing objects, which belong to object classes, to be stored in tables.
Because the format of data items within a database is dictated by the logical container to which it belongs, data items cannot be freely moved among logical containers. For example, a row from an employee table that contains an employee name, address and phone number cannot be moved into a products table that has columns for an item number, brand and price.
Unlike logical containers, schemas typically do not dictate the format of their members. However, schema membership is tied to user identity. A schema is a collection of objects that are owned by a particular user. Schema objects are the logical structures that directly refer to the database's data. Schema objects include such structures as tables, views, sequences, stored procedures, synonyms, indexes, clusters, and database links. Because schema membership is tied to user identity, schemas do not provide useful groupings that are not tied to user identities.
The inflexibility of the logical groupings within a database can make certain tasks complex and inefficient. For example, consider a situation in which numerous companies store highly confidential information about employees in a single employee table, and about products in a single product table. Potentially, each of the companies would have data in each of the two tables that it does not want the other companies to be able to see. Under these conditions, it would be desirable to assign permissions to the data within the tables based on the company of the user that entered the information. However, because there is no correlation between the logical grouping of the data (i.e. the two tables) and the criteria upon which permissions are to be assigned, the task of assigning the permissions becomes difficult. A similar difficulty is encountered if the same set of permissions is to be assigned to a group of schema objects that do not belong to the same schema, or a subset of the schema objects within a single schema.
Based on the foregoing, it is clearly desirable to overcome the inflexibility inherent in the logical grouping mechanisms available in current database systems.